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ABSTRACT 


In a publish/subscribe data processing broker network hav- 
ing a plurality of broker data processing apparatuses each of 
which has an input for receiving pubhshed messages directly 
from a publisher application and/or receiving subscription 
data from a subscriber application, a first broker data pro- 
cessing apparatus has: a unit for receiving a data message 
published on a first topic by a first publisher application; and 
a unit for forwarding the received pubhshed data message to 
a subscriber application which has requested, by entering 
subscription data, to receive a message on the first topic; 
wherein the first broker data processing apparatus sends a 
declaration to at least one other broker data processing 
apparatus of said plurality of broker data processing appa- 
ratuses declaring that the first broker data processing appa- 
ratus is the only broker data processing apparatus that is 
directly communicating with a pubMsher apphcation that is 
publishing on the first topic. 

7 Claims, 2 Drawing Sheets 
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1 

PUBLISH AND SUBSCRIBE DATA 
PROCESSING APPARATUS, METHOD AND 
COMPUTER PROGRAM PRODUCT WITH 
DECLARATION OF A UNIQUE PUBLISHER 
BROKER 

FIELD OF THE INVENTION 

The present inveation relates to the field of data process- 
ing and more specifically to data processing which distrib- 
utes messages from suppliers (called, hereinafter, 
"publishers") of data messages to consumers (called, here- 
inafter "subscribers") of such messages. 

BACKGROUND OF THE INVENTION 

Publish/subscribe data processing systems have become 
very popular in recent years as a way of distributing data 
messages from publishing computers to subscribing com- 
puters. The increasing popularity of the Internet, which has 
connected a wide variety of computers all over the world, 
has helped to make such publish/subscribe systems even 
more popular. Using the Internet, a World Wide Web 
browser application (the term "appUcation" or "process^* 
refers to a software program, or portion thereof, running on 
a computer) can be used in conjimction with the publisher or 
subscriber in order to graphically display messages. Such 
systems are especially useful where data supplied by a 
publisher is constantly changing and a large number of 
subscribers needs to be quickly updated with the latest data. 
Perhaps the best example of where this is useful is in the 
distribution of stock market data. 

In such systems, publisher applications of data messages 
do not need to know the identity or location of the subscriber 
applications which will receive the messages. The publish- 
ers need only connect to a publish/subscribe distribution 
agent process (the terms "distribution agent" and "broker" 
are used interchangeably herein), which is included in a 
group of such processes making up a broker network, and 
send messages to the distribution agent process, specifying 
the subject of the message to the distribution agent process. 
The distribution agent process then distributes the pubhshed 
messages to subscriber applications which have previously 
indicated to the broker network that they would like to 
receive data messages on particular subjects. Thus, the 
subscribers also do not need to know the identity or location 
of the publishers. The subscribers need only connect to a 
distribution agent process. 

One such publish/subscribe system which is currently in 
use, and which has been developed by the Transarc Corp. (a 
wholly owned subsidiary of the assignee of the present 
patent application, IBM Corp.) is shown in FIG. 1. Publish- 
ers 11 and 12 connect to the publish/subscribe broker 
network 2 and send published messages to broker network 
2 which distributes the messages to subscribers 31, 32, 33, 
34. Publishers 11 and 12, which are data processing appli- 
cations which output data messages, connect to broker 
network 2 using the well known interapplication data con- 
nection protocol known as remote procedure caU (or RFC). 
Each publisher application could be running on a separate 
machine, alternatively, a single machine could be running a 
plurality of publisher applications. TTie broker network 2 is 
made up of a pluraUty of distribution agents (21 through 27) 
which are connected in a hierarchical fashion which wUl be 
described below as a "tree structure". These distribution 
agents, each of which could be running on a separate 
machine, are data processing applications which distribute 
data messages through the broker network 2 from publishers 
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2 

to subscribers. Subscriber applications 31, 32, 33 and 34 
connect to the broker network 2 via RPC in order to receive 
published messages. 
Publishers 11 and 12 first connect via RPC directly to a 

5 root distribution agent 21 which in tura connects via RPC to 
second level distribution agents 22 and 23 which in turn 
connect via RPC to third level distribution agents 24, 25, 26 
and 27 (also known as "leaf distribution agents" since they 
are the final distribution agents in the tree stmcture). Each 
distribution agent could be running on its own machine, or 
alternatively, groups of distribution agents could be running 
on the same machine. The leaf distribution agents connect 
via RPC to subscriber appUcations 31 through 34, each of 
which could be running on its own machine. 

In order to allow the broker network 2 to determine which 
published messages should be sent to which subscribers, 
publishers provide the root distribution agent 21 with the 
name of a distribution stream for each published message. A 
distribution stream (called hereinafter a "stream") is an 
ordered sequence of messages having a name (e.g., "stock" 

20 for a stream of stock market quotes) to distinguish the stream 
from other streams. Likewise, subscribers provide the leaf 
distribution agents 31 through 34 with the name of the 
streams to which they would like to subscribe. In this way, 
the broker network 2 keeps track of which subscribers are 

25 interested in which streams so that when publishers publish 
messages to such streams, the messages can be distributed to 
the corresponding subscribers. Subscribers are also allowed 
to provide filter expressions to the broker network in order 
to limit the messages which wiU be received on a particular 

30 stream (e.g., a subscriber 31 interested in only IBM stock 
quotes could subscribe to the stream "stock" by making an 
RPC call to leaf distribution agent 24 and include a filter 
expression stating that only messages on the "stock" stream 
relating to IBM stock should be sent to subscriber 31). 

35 The above-described publish/subscribe architecture pro- 
vides the advantage of central coordination of all published 
messages, since all publishers must connect to the same 
broker (the root) in order to publish a message to the broker 
network. For example, total ordering of published messages 

40 throughout the broker network is greatly facihtated, since 
the root can easily assign sequence numbers to each pub- 
lished message on a stream. However, this architecture also 
has the disadvantage of publisher inflexibility, since each 
publisher is constrained to publishing from the single root 

45 broker, even when it would be much easier for a publisher 
to connect to a closer broker. 

Accordingly, pubhsh/subscribe software designers are 
beginning to consider architectures where publishers are 
allowed to publish messages directly to any broker in the 

50 broker network. This clearly has the advantage of removing 
the above-mentioned constraint on publishers. However, as 
with any tradeoff, it presents oUier problems. One of the 
major problems is that since a publisher can publish from 
any broker, subscription data (data indicating which sub- 

55 scribers have subscribed to which streams/topics) must be 
propagated throughout the broker network, as it cannot be 
determined from where a pubtisher on a particiUar topic/ 
stream will publish from. Propagating subscription data 
throughout the broker network is the only way (besides 

60 sending aU pubhshed messages to every broker) to guarantee 
that published messages, from wherever they may be 
pubhshed, will make their way to the subscribers who have 
requested the messages. This requirement imposes a great 
strain on the broker network, as it not only presents a high 

65 data traffic level throughout the network but also the sub- 
scription data must be locally stored and maintained with 
respect to each broker in the broker network. 
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SUMMARY OF THE INVENTION publish a stock quote message to stream "stock's publisher 

A A - 4 * *u *• *■ J • 11 makes an RFC call to the root distribution agent H which 

According to one aspect, the present mvention provides ID • . , i r . . i ^ uuwa^vuxA 

a publish/subscribe data processing broker network having a "'^ '°P l^^el of tlie broker network tree structure. In thrs 

plurality of broker data processing apparatuses each of f^^scnber application 32, running on another 
u- uu • *f ■ • ui- I- J J' *i 5 computer, has sent a subscnption request via an RFC call to 

which has an input for receivmg published messages directly ^ c.-.l • J' / H"^y^^ ^^'^^'^ 

f „ .1- . V . . . ... le at distnbution agent 24, which IS at the bottom level of the 

from a publisher apphcation and/or receiving subscnpUon , , , • 7- \, . au tLiw i^^tiv^ixi i^v^i ti^v 

A . f u-u T*- ii.t- i J. tree structure, indicatme that subscriber 32 would like to 

data from a subscriber application, a first broker data pro- . ' i » vvuum lu^^ lu 

. . e • - J . subscribe to stream stock . 
cessing apparatus comprising: means for receiving a data 

message published on a first topic by a first publisher ^h^^, whenever publisher 11 publishes a data message to 

application; and means for forwarding the received pub- ^^re^^ "stock" the distribution tree structure of broker 

lished data message to a subscriber application which has network 2 channels the message down through the root 

requested, by entering subscription data, to receive a mes- distribution agent 21, through any intermediary distribuUon 

sage on the first topic; wherein the first broker data process- ^S^nts (e.g., 22 in the example of FIG. 1) and through the 

ing apparatus sends a declaration to at least one other broker ^^^^ distribution agent 24 to the subscriber 32. This involves 

data processing apparatus of said pluraUty of broker data a series of RFC calls being made between each successive 

processing apparatuses declaring that the first broker data ^^^^^^ ^® diagram of FIG. 1 connecting publisher 11 and 

processing apparatus is the only broker data processing subscriber 32 (i.e., 11 to 21, 21 to 22, 22 to 24 and 24 to 32), 

apparatus that is directly communicating with a publisher FIG. 2 shows a different publish/subscribe architecture 

application that is publishing on the first topic. where publisher applications can publish messages to the 

According to a second aspect, the present invention ^° ^^^^^ network by directly communicating with any one of 

provides a data processing method having method steps ^ plurality of distribution agents (brokers). For example, 

corresponding to each clement of the data processing appa- publisher application 201 is shown communicating direcUy 

ratus of the first aspect of the invention ^i^'^ Broker 12. There is no requirement in this architecture 

According to a third aspect, the present invention pro- 25 publisher applications communicate directly with a 

vides a computer readable storage r^^edium having a com- ^""^ distribution agent. Publisher application 201 

puter program stored on it which, when executed on a ^an potentiaUy ™umcate directly 

computer, carries out the fimctionality of data processing ^^^^^ agents shown m HO. 2, in the described examples 

method of the second aspect of the invention. J^^^^ commumcatmg directly with Broker 

The present invention allows one broker in a network of 30 c u *u v ^- ^'^m uim * 

uui ^ujij • Subscnber applications 202 and 203 would like to receive 

such brokers, to be declared as the unique source of taking ^ ^ • .i. . ui- l i- 

. ,. . i • . 4 1 r 1 . • messages on the stream/topic that publisher application 201 

published messages into the network for a particular topic. . uf- u- ^ if -u i- ^>«'^ ^ ^r.^^ 

^ f=> f y ^ publLshing on. Thus, subscriber apphcations 202 and 203 

Thus, with the present invention, since a publisher appli- communicate directly with Brokers 1112 and 1221, 

cation can be declared as the unique source of publications respectively, to provide subscription data thereto informing 

on a stated topic in the network, the problem that existed in the broker hierarchy of their desire to receive such published 

the prior art of requirmg subscnption data to be propagated, messages. Since the publisher appHcaUon 201 is aUowed to 

mamtained and stored by each distnbution agent throughout communicate directly with any of a pluraHty of distribution 

the broker hierarchy no longer exists. Specifically, the agents, the subscription data entered by the subscriber 

problem no longer exists because there is no more uncer- applications must be propagated throughout the broker net- 

tainty regarding where a publisher application might publish ^^^^ ^^^^ ^^^^^^ ^ 2. This way, no matter 

from. Thus, subscnption data need only be propagated to ^hi^h distribution agent the publisher apphcation 201 hap- 

and maintamed on distnbution agents which are included in pens to communicate direcUy with, the pubhshed messages 

a direct path between the unique broker source on the stated ^1 ^e able to be routed to the subscriber apphcations 202 

topic and a subscriber which has subscribed to that topic, ^nd 203. As stated above, however, this creates a high 

BRIEF DESCRIFTION OF THE DRAWINGS performance overhead due to the excessive amounts of 

subscription data propagation trafiSc throughout the broker 

The invention will be better understood by referring to the network and due to the need to have to maintain and store 

detailed description of the preferred embodiments which such subscription data locally at each distribution agent, 

will now be described in conjunction with the following jf a distribution agent (also referred to herein as a 

drawing figures: "broker") can be identified to the other distribution agents as 

FIG. 1 shows the architecture of a prior art publish/ the home to all publisher applications (e.g. by topic content 

subscribe broker network which was referred to above; and or a publisher flag) on a given topic, call this a unique 

FIG. 2 shows the architecture of a publish/subscribe pubUsher broker for simplicity, it is possible to restrict the 
broker network according to which the prefencd cmbodi- S5 subscription path in the hierarchy by halting the propagation 

ment of the present invention will be explained below. of the subscription data once this unique publisher broker is 

reached. 

DETAILED DESCRIPTION OF THE To further the Umiting of subscription propagation in the 

FREFERRED EMBODIMENTS y^jqyg publisher broker case it is possible to remove sub- 
In the prior art FIG, 1 discussed above, a publisher 60 scriptions that have been propagated down branches of the 

application 11, running on one computer, is, for example, a hierarchy leading off the path between the subscriber and the 

suppHer of live stock market data quotes. That is, publisher publisher that contain no subscriptions or the publisher on 

application 11 provides frequent messages stating the this topic, thus, reducing the subscriptions for a topic to only 

present value of share prices. In this example, publisher lie on the path(s) between the subscriber's (or subscribers') 
application 11 is publishing messages on a stream called 65 broker(s) and the publisher's broker, 

"stock" which has already been configured in the broker The first level of subscription data propagation restriction 

network 2. As is well known, when pubhsher 11 wishes to prevents subscription data from flowing further once the 
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unique publisher broker is reached by the subscription data. 
When a subscription for a topic arrives at a unique publisher 
broker and the topic matches the topic on which this broker 
is the unique publisher broker, the unique publisher broker 
will not propagate the subscription any further through the 5 
hierarchy as it is known that no other broker can possibly 
publish on this topic. For example, if a new subscriber 
application 203 attaches to its nearest Broker 1221 aiid 
enters a subscription to a certain topic (e.g., IBM stock 
price), this subscription data identifying the new subscrip- 
tion will propagate up to Broker 122 and then further up to 
Broker 12 (which has previously declared itself to the other 
brokers as the unique publisher broker on the topic of IBM 
stock price). Broker 12 will then recognize that the sub- 
scription data's topic (IBM stock price) matches the topic 15 
(IBM slock price) on which Broker 12 is the unique pub- 
Hsher broker, and thus Broker 12 will not further propagate 
the subscription data to Broker 121 or Broker 1. 

The second level of limiting subscription data propagation 
is the removal of unnecessary subscriptions which has 20 
already been propagated to brokers, i.e., those subscriptions 
that do not lie on the path(s) between subscriber(s) and the 
unique publisher broker, once a new unique publisher broker 
is added to an existing broker hierarchy. Any unnecessary 
subscriptions can be identified by the fact that they would 25 
cause publications to flow in the opposite direction from 
those originating from the unique publisher broker, which is 
not possible for they would have to have originated from a 
publisher on another broker, and thus, the publisher broker 
could not be unique. 30 

The preferred embodiment involves the use of a special 
message (for example, a publication), call it a unique 
publisher broker message, this contains the topic concerned 
and the identity of the broker that has just sent this message. 
A broker receiving a unique publisher message will follow 35 
these rules: 

1) If this broker also claims to be a unique publisher broker 
on this same topic we have a situation where more than 
one broker in the hierarchy believe they are unique 
publishers on the same topic, this cannot be valid and an 40 
error is reported. Otherwise: The broker marks the topic 
that matches the one in the message as being a unique 
publisher topic. 

2) If the broker has a subscription from the broker that sent 
this message, the subscription can be removed. This is 45 
because the subscription could only be used if a pubhca- 
tion arrived at this broker and was to be propagated 
towards the broker sending the unique publisher message. 
This would cause publications to flow towards the pub- 
lisher which is not possible when the publisher is unique. 50 
The identity of the broker sending this message is 
replaced with the identity of the current broker and the 
message is then propagated to every relation known to 
this broker, except the one that originated the unique 
publisher message. 55 
Now we define the three scenarios that can cause a unique 

publisher message to be generated by a imique publisher 
broker and how they are handled: 

1) Subscriber applications subscribe to a topic by commu- 
nicating directly (e.g., via RFC) with one of the brokers, 60 
and the subscriptions (i.e., subscription data) are propa- 
gated to all brokers before a unique publisher has been 
identified. When a broker (e.g.. Broker 12) declares that 
it is the unique publisher broker on this topic and 
subscription(s) already exist, the unique pubhsher broker 65 
(e.g.. Broker 12) marks the topic as being unique and a 
unique publisher message is generated and sent to all 
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relations (meaning, all brokers that are direct neighbours) 
of this broker (e.g.. Brokers 121, 122 and 1). By following 
the above rules this message will be propagated to all 
brokers and any redundant subscriptions will be removed 
from the hierarchy. 

2) Before any subscriptions are made, a publisher broker 
(e.g., broker 12) believes that it is a unique publisher 
broker on a certain topic (e.g, IBM stock price). A 
subscription to this topic then arrives at broker 12 from 
another broker (e.g., broker 1), once a subscriber appli- 
cation 202 has entered a subscription (e.g., by directly 
communicating the subscription data to broker 1112, 
which has resulted in corresponding subscription data 
propagating to brokers 111, 1111, 11, 112, 1121, 1 and 
finally to broker 12). At this point (when the subscription 
data reaches broker 12) we hall propagation of the sub- 
scription past broker 12, and broker 12 generates a unique 
publisher message and sends it to the broker 1 that sent the 
subscription data to broker 12. Again, by following the 
above rules this unique publisher message will be propa- 
gated fi-om broker 1 to all brokers (i.e., 11, 112, 1121, 111, 
1112 and Ull) that have received the original subscrip- 
tion data. Then, the subscription data is removed from 
those brokers (i.e., 112, 1121, 1111) lying off the direct 
path between the unique publisher broker 12 and the 
subscriber application 202. 

3) A unique publisher broker 12 exists along with subscriber 
202 and a direct path (i.e., from subscriber 22 to broker 
1112 to broker 111 to broker 11 to broker 1 to broker 12) 
between tbem has been formed. Tlien, a new subscription 
(from a new subscriber 204, shown in dotted line, is made 
from a broker 1121 that lies in a branch off a direct path 
from the unique publisher broker 12 to an existing sub- 
scriber 202. When the new subscription data arrives at 
broker 11 (which is on the direct path mentioned above) 
and the topic of the subscription has been marked as a 
unique pubhsher topic and a subscription to this topic 
already exists it is now known that we have intercepted a 
direct path between a pubhsher and a subscriber. The 
propagation of the subscription is halted at broker 11 (i.e., 
the subscription data has already propagated from broker 
1121 to broker 112 to broker 11), as a subscription to this 
topic would already have been propagated from broker U 
to the unique publisher broker 12 due to the existing 
subscription. A unique publisher message is then gener- 
ated by broker U and sent back to the broker 112 that sent 
the new subscription. This is the same as the scenario 
above, only for a sub-tree of the broker hierarchy. 
While the preferred embodiment of the invention has been 

discussed in the context of a broker network made up of a 
hierarchy (e.g., designed from the top down) of distribution 
agents, the broker network need not be hierarchical. For 
example, the network could also be configured as a totally 
connected network, with each broker connected to every 
other broker (or some other combination of brokers less than 
every other broker). 
We claim: 

1. In a pubhsh/subscribe data processmg broker network 
having a plurality of broker data processing apparatuses 
each of which has an input for receiving published messages 
directly from a publisher application and/or receiving sub- 
scription data from a subscriber application, a first broker 
data processing apparatus comprising: 

means for receiving a data message published on a first 
topic by a first pubhsher application; and 

means for forwarding the received published data mes- 
sage to a subscriber application which has requested, 
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by entering subscription data, to receive a message on 
the first topic; 

wherein the first broker data processing apparatus sends a 
declaration to at least one other broker data processing 
apparatus of said plurality of broker data processing ^ 
apparatuses declaring that the first broker data process- 
ing apparatus is the only broker data processing appa- 
ratus that is directly communicating with a publisher 
application that is publishing on the first topic. 

2. The apparatus of claim 1 wherein a second broker data 
processing apparatus, which is on a direct path between the 
first broker data processing apparatus and a subscriber 
application, sends the declaration on behalf of the first 
broker data processing apparatus upon receiving new sub- 
scription data from a new subscriber application to the first 15 
topic. 

3. The apparatus of claim 1 wherein upon receipt of the 
declaration subscription data is removed from broker data 
processing apparatuses that do not lie on a direct path 
between the first broker data processing apparatus and the ^ 
subscriber application. 

4. The apparatus of claim 1 wherein the network is the 
Internet. 

5. The apparatus of claim 1 wherein at least one of the 
publisher application and the subscriber application runs in 25 
cooperation with a World Wide Web browser application, 

6. In a publish/subscribe data processing broker network 
having a plurality of broker processing apparatuses each of 
which has an input for receiving published messages directly 
from a publisher application and/or receiving subscription 
data from a subscriber application, a method carried out by 
a first broker data processing apparatus, the method com- 
prising steps of: 

receiving a data message published on a first topic by a 
first publisher application; and 
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forwarding the received published data message to a 
subscriber application which has requested, by entering 
subscription data, to receive a message on the first 
topic; 

wherein the first broker data processing apparatus sends a 
declaration to at least one other broker data processing 
apparatus of said plurality of broker data processing 
apparatuses declaring that the first broker data process- 
ing apparatus is the only broker data processing appa- 
ratus that is directly communicating with a publisher 
application that is publishing on the first topic. 
7. In a publish/subscribe data processing broker network 
having a plurality of broker data processing apparatuses 
each of which has an input for receiving published messages 
directly from a publisher application and/or receiving sub- 
scription data from a subscriber application, a computer 
program product embodied on a computer readable storage 
medium for, when nm on a computer, carrying out a method 
on a first broker data processing apparatus, the method 
comprising steps of: 

receiving a data message published on a first topic by a 

first publisher application; and 
forwarding the received published data message to a 
subscriber apphcation which has requested, by entering 
subscription data, to receive a message on the first 
topic; 

wherein the first broker data processing apparatus sends a 
declaration to at least one other broker data processing 
apparatus of said plurality of distribution agent data 
processing apparatuses declaring that the first broker 
data processing apparatus is the only broker data pro- 
cessing apparatus that is directly communicating with a 
publisher application that is publishing on the first 
topic. 
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[57] ABSTRACT 

A private network is built by first allowing a pre-determined 
number of client systems to connect directly to a server 
system. After this occurs, additional client systems request- 
ing connection are furnished with the addresses of client 
systems already connected within the private network. Each 
of the additional client systems then makes connections with 
a multiple number of client systems to receive information 
from the server system. Each of these client systems sub- 
sequendy accepts connections from up to a second pre- 
determined number of client systems to which it transmits 
information received from the server system. 

15 Claims, 5 Drawing Sheets 
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METHOD FOR CONNECTING CLIENT 
SYSTEMS INTO A BROADCAST NETWORK 

BACKGROUND OF THE INVENTION 

1. Field of the Invention ^ 
This invention relates to a method for making connections 

on the Internet, and, more particularly, to a method for 
causing connections to be made among client systems. 

2. Background Information lO 
The conventional structure of the Internet is based on 

combinations of clients and servers, in which the client 
systems obtain information from the servers. Thus, to 
retrieve information, an individual client system makes a 
connection with a server and requests the particular infor- ^5 
mation needed. The information is then sent from the server 
to the client. With this method, each client has an individual 
connection to the server. If there are too many connections 
to the server to allow a new connection to be established, a 
client wishing to make an additional connection is denied 
access. What is needed is a way to increase the number of 
clients which can be connected to a single server without 
requiring a substantial increase in the server hardware to 
provide additional ports. 

Some servers provide what appears to be a broadcasting 
function by relaying information from one client connected 
to the server to all other clients connected to the same server 
An example of this type of information sharing is found in 
the "chat relay" server protocol. However, this type of 
interconnection is also limited by the number of clients 
which can be connected to the server. Again, what is needed 
is a way to increase the number of clients which can be 
interconnected in a substantial way. 

SUMMARY OF THE INVENTION 

In accordance with one aspect of the invention, there is 
provided a process for connecting client systems within a 
private network. This process includes the steps of connect- 
ing client systems, up to a first pre-determined maximum 40 
number of systems, directly to a server system through a 
public network, and connecting additional client systems, 
beyond the first pre-determined maximum number, to other 
client systems to form the private network extending 
through connections within the public network to the server 45 
system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

no. 1 is a diagrammatic view of a private network built 
into a pyramid in accordance with the present invention; 

FIG. 2 is a block diagram of a computing system, repre- 
senting either a server system or a client system in FIG, 1; 

FIG. 3 is a flow chart of processes occuring in the server 
system of FIG. 1 to provide for the connection of client 55 
systems into the private network of FIG. 1 or for their 
disconnection therefrom; 

FIGS. 4A-4B is a flow chart of processes occuring in the 
server system of FIG. 1 to provide for the connection of 
client systems into the private network of FIG. 1 or for their go 
disconnection therefrom, with FIG. 4A being an upper 
portion of FIG, 4, and with FIG. 4B being a lower portion 
thereof; and 

FIG, 5 is a table showing the number of systems in a last 
row of the network of FIG. 1, and the total number of 65 
systems in the network, as a function of the number of rows 
therein. 
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DETAILED DESCRIPTION 

FIG. 1 is a diagrammatic view of a private network built 
into a pyramid in accordance with the present invention, 
showing connections established among a single server and 
various clients. In this diagram, the single server is indicated 
as A, and the clients are indicated as C, followed by 
numerals as required for identification. 

The establishment of this network structure is begun as 
the client CI requests a connection to the private network by 
sending a message to server A. Since a connection can be 
made directly the server A, with client CI being the first 
client to connect, the server A responds by teUing the client 
CI to establish a direct connection to the server. The same 
procedure if followed when a second client C2 requests a 
connection to the private network. 

However, in the example of FIG, 1, only two connections 
can be made directly to the server A. Therefore, when a new 
client C3 requests a connection from the server A, it receives 
an instruction from server A to connect to client CI, and also 
to C2 in case CI goes down. Similarly, additional clients C4, 
C5, and C6 are connected to clients CI and C2. 

The expanding structure of the private network is deter- 
mined by the number of clients which are allowed to connect 
to each client. In the example of FIG, 1, each client, except 
for CI and C2, is connected upward to two clients, and each 
client, except for those at the bottom, or end, of the stmcture, 
is connected to four clients below. Thus, with these 
exceptions, each client is connected to two additional clients 
for receiving information, so that continuity is maintained if 
a client goes down, and up to four clients for disseminating 
information. The server A sends information from a database 
of data to be broadcast to the clients to which it is directly 
connected, in this example to clients CI and C2. These 
clients, and those below them, in turn relay the data firom one 
level to another. 

FIG. 2 is a block diagram of a computing system, which 
represents both the server A of FIG. 1 and ono of the client 
systems C, also shown in FIG. 1, This computing system 9 
includes a processor 10, associated system memory 12, a 
hardfile 14, a disk drive 16 for reading a floppy disk 18, and 
a number of output ports 20 for connections with client 
systems. 

The program connecting server A with these client sys- 
tems in accordance with this invention is preferably written 
on one or more diskettes 18, to be loaded within the server 
A into system memory 12 and hardfile storage 14 through 
the disk drive 16. The hardfile 14 also includes a database 22 
holding a list of all clients presently connected to the private 
network, with their IP (Internet Protocol) addresses. While 
this database 22 is shown as residing in the hardfile 14, it 
may reside additionally, partially, or alternately in system 
memory 12, facilitating rapid access to the address infor- 
mation. 

The program connecting a client system C to server A 
through other client systems C in accordance with this 
invention is loaded within the client system C into system 
memory 12 and hardfile 14 from one or more diskettes 18, 
Alternately, this program may be downloaded through net- 
work connections between the server A and the client C into 
the system memory 12 of the client C for execution by the 
processor 10 and for storage within the hardfile 14. 

FIG. 3 is a flow chart of processes occurring within the 
server A (shown in FIG. 1) operating in accordance with the 
present invention to provide for the connection of client 
systems to the private network and for their disconnection 
therefrom. 
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Referring to FIGS. 2 and 3, in block 24, the server A is 
waiting for an incoming request from a client, which may be 
either a request for a new connection or a notification from 
a disconnection of an existing connection. A notification of 
disconnection is sent to server A by a system which has been 
connected to the system disconnecting from the private 
network, but which is one conneaion farther away from the 
server than the disconnecting system. Thus, the system 
notifying the server of a disconnection has just lost one of its 
two private network connections for receiving information 
from server A. 

When a request is received, a determination is made in 
block 26 of whether it is a request for connection. If the 
request is a request for connection, a determination is made 
in block 28 of whether a port 20 of the server A is available. 
In the example of FIG. 1, the connections of chents CI and 
C2 were made directly to the server because a port 20 was 
available when the connection request was made. Thus, if a 
port 20 is available, as determined in block 28, the client 
making the request is connected to the port in block 30. If 
a port 20 is not available, in block 32, the server A looks up 
two available IP addresses within its database 22 and returns 
this information to the requesting client. Next, in block 34, 
the server A logs the IP address of the client which has made 
the request into the database 22, so that additional clients 
may subsequently be connected to this new element within 
the private network. Then the server A returns to block 24 to 
wait for the next request. 

On the other hand, if the request to server A is determined 
in block 26 not to be a request for connection, a determi- 
nation is made in block 36 of whether it is a notification of 
a disconnection. If it is not such a notification, in block 38, 
the server A disconnects the cHent system making the 
request from the private network, as it has made an invaUd 
request. If it is determined in block 36 that the request is a 
notification of disconnection, in block 40 the address of the 
disconnected client is removed from database 22. Next, in 
block 42, server A looks up an additional available IP 
address within the database 22 and returns this information 
to the client providing notification of a disconnection, so that 
it can re-establish a second data link through a new client 
whose address has been provided. Then the server returns 
again to block 24 to wait for another request to process. 

FIG. 4 is a flow chart of processes occurring within the 
client C (shown in FTG. 1) operating in accordance with the 
present invention to provide for the connection of client 
systems to the private network and for their disconnection 
therefrom. 

Referring to FIGS. 1 and 4, these processes begin with the 
system in start block 46, waiting for a request for a new 
connection. In start block 46, the system may be, for 
example, performing calculations or providing other func- 
tions for its user. The command to make a new connection 
may come from a tiser interaction with the system. After this 
command occurs, as determined in block 48, a request for a 
connection is sent to the server A in block 50. Then the 
server connects the client system directly to itself, if a port 
for such a connection is available, or sends two new 
addresses. If the new addresses are sent, as determined in 
block 52, connection is made to the new addresses in block 
54. Otherwise, a direct connection is made to the server in 
block 56. 

In either case, the server A can now instruct up to four 
other client systems C to connect to the client executing the 
processes of FIG. 4. Thus, when such a connection request 
is received from another client, as determined in block 58, 
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the connection is accepted in block 60. If one of the two 
systems to which the client C is connected becomes discon- 
nected for any reason, as determined in block 62, the cUent 
C transmits a disconnection notification to the server A in 
block 64. When the server subsequently responds with a new 
address, as determined in block 66, a connection is made to 
the new address in block 68. Connection within the private 
network may be terminated, for example, at the request of 
the user, at any time. When this occurs, as determined in 
block 70, the client system returns to the start in block 46. 

FIG. 5 is a tabular view of the number of client systems 
C which may be connected in the last row (i.e. the row 
farthest from the server A), together with the total number of 
client systems C as a function of the number of client system 
rows in the private network stmcture. In general, the last row 
is only partly filled, with a total number of client systems 
other than one of the total numbers listed in FIG. 5. 

The table of FIG. 5 reflects the assumptions of FIG. 1, that 
two client systems are directly connected to the server 
system, that each other client system is connected to receive 
information from the server system through two other client 
systems, and that each client system, except for the last row 
thereof, has four other client systems connected to it to 
receive such information. While these pre -determined rules 
for connection are used to form the structure of the private 
network, they may be changed to vary the structure of the 
private network, or to account for various hardware 
configurations, within the scope of the present invention. 

While the invention has been described in its preferred 
form or embodiment with some degree of particularity, it is 
understood that this description has been given only by way 
of example and that numerous changes in the details of 
constmction, fabrication and use, including the combination 
and arrangement of parts and process steps, may be made 
without departing from the spirit and scope of the invention. 

What is claimed is: 

1. A process for connecting client systems within a private 
network, wherein said process comprises the steps of: 

(a) connecting client systems, up to a first pre-determined 
maximum number thereof, directly to a server system 
through a public network; 

(b) connecting additional client systems within a plurality 
thereof, beyond said first pre-determined maximum 
number thereof, to other client systems to form said 
private network extending through connections within 
said public network to said server system; 

wherein each client system within said plurality thereof is 
connected to a second pre -determined number of chcnt 
systems within said plurality thereof through said pub- 
lic network for receiving information from said server 
system; 

wherein each said client system is conneclable to up to a 
pre-determined number of client systems for transmit- 
ting information through said public network from said 
server system; 

Wherein said step (b) includes the steps of: 

(d) transmitting a request for connection from an addi- 
tional client system within said plurality thereof to 
said server systems; 

(e) transmitting addresses, of said second pre- 
determined number of available client systems con- 
nected within said private network, to said additional 
client system from said server system; and 

(f) establishing connections between said additional 
client system and said second pre-determined num- 
ber of available client systems connected within said 
private network. 
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2. The process of claim 1, additionally comprising a step 
(c) of maintaining said second pre-detennined number of 
connections between each client system within said plurality 
thereof and other client systems within said plurality thereof, 
for receiving information from said server system by estab- 
lishing new connections among said client systems when a 
disconnection occurs. 

3. The process of claim 1, wherein each available client 
system within said second pre -determined number thereof 
has connected thereto for receiving information therefrom 
fewer than a third pre -determined number of client systems 
within said plurality thereof. 

4. The process of claim 2, wherein said step (c) includes 
the steps of: 

(g) transmitting a disconnection notification to said server 
system from a partly disconnected client system within 
said plurality thereof, wherein said partly disconnected 
client system has been connected for receiving infor- 
mation from said server system to a client system 
disconnecting from said private network; 

(h) transmitting, from said server system to said partly 
disconnected client system, an address of an available 
client system within said plurality thereof connected 
within said private network; and 

(i) establishing a connection between said available client 
system and said partly disconnected client system. 

5. The process of claim 4, wherein said available client 
system has connected thereto for receiving information 
therefrom fewer than a third pre-determined number of 
client systems within said plurality thereof. 

6. A process executing within a server system for estab- 
lishing a private network of client systems within a plurality 
thereof to receive information from said server system, 
wherein said process comprises the steps of: 

(a) receiving a request for connection from a client system 
issuing said request; 

(b) determining if a port of said server system is available 
for connection with said private network; 

(c) if a port of said server system is available for con- 
nection within said private network, as determined in 
step (b), connecting said client system issuing said 
request to said port; 

(d) if a port of said server system is not available for 
connection within said private network, as determined 
in step (b), sending to said client system issuing said 
request a first pre-determined number of addresses of 
available cUent systems within said plurality thereof 
connected within said private network; and 

(e) adding an address of said client system issuing said 
request to a list of addresses within a database residing 
in said server system. 

7. The process of claim 6, comprising in addition the steps 

of: 

(f) receiving a disconnection notification from a partly 
disconnected system within said private network, 
wherein said partly disconnected client system has been 
connected for receiving information from said server 
system to a client system disconnecting from said 
private network; 

(g) sending to said client system issuing said disconnec- 
tion notification an address of a client system within 
said plurality thereof connected within said private 
network; and 

(h) removing an address of said client system disconnect- 
ing from said private network from a database includ- 
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ing addresses of client systems connected within said 
private network. 

8. The process of claim 7, wherein, within said steps (d) 
and (g) said available client systems have fewer than a 
second predetennined number of client systems attached 
thereto for transmitting information received from said 
server system. 

9. A process executing within a particular client system 
for establishing a private network of client systems within a 
plurality thereof to receive information from a server 
system, wherein said process comprises the steps of: 

(a) transmitting a connectioa request to said server sys- 
tem; 

(b) receiving addresses of available client systems within 
said private network from said server system; 

(c) connecting to said avaUable client system for receiving 
information from said server system; 

(d) receiving a connection request from an additional 
client system within said plurality thereof; and 

(e) establishing a connccUoa with said additional client 
system to transmit information received from said 
server system. 

10. The process of claim 9, additionally comprising the 
steps of: 

(f) being disconnected from a first client system con- 
nected within said private network between said par- 
ticular client system and said server system; 

(g) U-ansmitting a notice of disconnection to said server 
system; 

(h) receiving an address of an available client system 
connected within said private network from said server 
system; and 

(i) establishing a connection with said available client 
system identified by said address received in step (h). 

11. A computer readable medium upon which coded steps 
are written for a process executing within a server system for 
establishing a private network of client systems within a 
plurahty thereof to receive information from said server 
system, wherein said process comprises the steps of: 

(a) receiving a request for connection from a client system 
issuing said request; 

(b) determining if a port of said server system is available 
for connection with said private network; 

(c) if a port of said server system is available for con- 
nection within said private network, as determined in 
step (b), connecting said client system issuing said 
request to said port; 

(d) if a port of said server system is not available for 
connection within said private network, as determined 
in step (b), sending to said client system issuing said 
request a first pre-determined number of addresses of 
available client systems within said plurality thereof 
connected within said private network; and 

(e) adding an address of said client system issuing said 
request to a list of addresses within a database residing 
in said server system. 

12. The medium of claim 11, wherein said process com- 
prises in addition the steps of: 

(f) receiving a disconnection notification from a partly 
disconnected system within said private network, 
wherein said partly disconnected client system has been 
connected for receiving information from said server 
system to a client system disconnecting from said 
private network; 
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(g) sending to said client system issuing said disconnec- 
tion notification an address of a client system within 
said plurality thereof connected within said private 
network; and 

(h) removing an address of said client system disconnect- 
ing from said private network from a database includ- 
ing addresses of client systems connected within said 
private network. 

13. The medium of claim 12, wherein, within said steps 
(d) and (g) said available client systems have fewer than a 
second predetermined number of client systems attached 
thereto for transmitting information received from said 
server system. 

14. A computer readable medium upon which coded steps 
are written for a process executing within a particular client 
system for establishing a private network of client systems 
within a plurality thereof to receive information from a 
server system, wherein said process comprises the steps of: 

(a) transmitting a connection request to said server sys- 
tem; 

(b) receiving addresses of available client systems within 
said private network from said server system; 
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(c) connecting to said available client system for receiving 
information from said server system; 

(d) receiving a connection request from an additional 
client system within said plurality thereof; and 

(c) establishing a connection with said additional client 
system to transmit information received from said 
server system. 

15. The medium of claim 14, wherein said process addi- 
ng tionally comprises the steps of: 

(f) being disconnected from a first client system con- 
nected within said private network between said par- 
ticular client system and said server system; 

(g) transmitting a notice of disconnection to said server 
IS system; 

(h) receiving an address of an available chent system 
connected within said private network from said server 
system; and 

(i) establishing a connection with said available client 
system identified by said address received in step (h). 
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